1. Field of the Invention
The invention relates to import and export of RAID logical volumes and in particular relates to importation of a RAID level 6 volume into a subsystem that does not support RAID level 6 and re-importation of such a volume back to a RAID level 6 subsystem.
2. Discussion of Related Art
Storage subsystems have evolved along with associated computing subsystems to improve performance, capacity, and reliability. Redundant arrays of independent disks (so called “RAID” subsystems) provide improved performance by utilizing striping features and provide enhanced reliability by adding redundancy information. Performance is enhanced by utilization of so called “striping” features in which one host request for reading or writing is distributed over multiple simultaneously active disk drives to thereby spread or distribute the elapsed time waiting for completion over multiple, simultaneously operable disk drives. Redundancy is accomplished in RAID subsystems by adding redundancy information such that the loss/failure of a single disk drive of the plurality of disk drives on which the host data and redundancy information are written will not cause loss of data. Despite the loss of a single disk drive, no data will be lost though in some instances the logical volume will operate in a degraded performance mode.
RAID storage management techniques are known to those skilled in the art by a RAID management level number. The various RAID management techniques are generally referred to as “RAID levels” and have historically been identified by a level number. RAID level 5, for example, utilizes exclusive-OR (“XOR”) parity generation and checking for such redundancy information. Whenever data is to be written to the storage subsystem, the data is “striped” or distributed over a plurality of simultaneously operable disk drives. In addition, XOR parity data (redundancy information) is generated and recorded in conjunction with the host system supplied data. In like manner, as data is read from the disk drives, striped information may be read from multiple, simultaneously operable disk drives to thereby reduce the elapsed time overhead required completing a given read request. Still further, if a single drive of the multiple independent disk drives fails, the redundancy information is utilized to continue operation of the associated logical volume containing the failed disk drive. Read operations may be completed by using remaining operable disk drives of the logical volume and computing the exclusive-OR of all blocks of a stripe that remain available to thereby re-generate the missing or lost information from the inoperable disk drive. Such RAID level 5 storage management techniques for striping and XOR parity generation and checking are well known to those of ordinary skill in the art.
RAID level 6 builds upon the structure of RAID level 5 but adds a second block of redundancy information to each stripe. The additional redundancy information is based exclusively on the data block portions of a given stripe and does not include the parity block computed in accordance with typical RAID level 5 storage management. Thus, the additional redundancy block for each stripe produces redundancy information orthogonal to the parity data redundancy information used in RAID level 5. Typically, the additional redundancy block generated and checked in RAID level 6 storage management techniques is orthogonal to the parity generated and checked in accordance with RAID level 5 standards.
In modern storage subsystems, disk drives are often integrated within an enclosure or box with little to no processing capabilities associated therewith. Such a box is often referred to as “just a box of disks” or “JBOD”. Whether configured as such a box or as individual disk drives devoid of such a common enclosure, it is common for large computing enterprises to move individual disk drives or multiple disk drives from one storage subsystem to another storage subsystem. Such movement may be for purposes of load balancing, security or other reasons unique to the computing enterprise. Such physical movement of disk drives or modules or boxes of disk drives is referred to herein as “drive migration” or “physical migration” and refers to the physical act of removing a disk drive or multiple disk drives from one storage subsystem and inserting them into another storage subsystem.
It is common in such storage subsystems to logically define one or more logical volumes such that each logical volume comprises some portion of the entire capacity of the storage subsystem. Each volume may be defined to span a portion of each of one or more disk drives in the storage subsystem. Multiple such logical volumes may be defined within the storage subsystem typically under the control of a storage subsystem controller. Therefore, for any group of disk drives comprising one or more disk drives, one or more logical volumes or portions thereof may physically reside on the particular subset of disk drives. It is common for a storage subsystem controller component (i.e., a RAID storage controller) to record configuration information about the known logical volumes on each disk drive in the storage subsystem. The configuration information (“configuration database”) records maintain information regarding which disk drives are used to form a portion of each logical volume. The storage controller updates such configuration information from time to time (i.e., as the configuration is changed) and may associate a version number, time stamp, or other indicia to indicate the validity of the configuration database.
Typically, before a subset of disk drives is physically migrated from a first storage subsystem to a second storage subsystem, all logical volumes associated with the disk drive to be migrated are disabled or otherwise made inaccessible to users of the first storage subsystem from which the disk drive are to be migrated. When a second storage subsystem first senses a new disk drive being inserted into its control, the configuration information contained on the inserted disk drive is read by the second storage subsystem (i.e., the destination of the disk drive migration) and logical volumes defined in that configuration database are merged with the definitions of logical volumes already known to the receiving second storage subsystem. When all disk drives required for any particular logical volume newly defined to the receiving second storage subsystem are finally inserted, that logical volume may be made available to users of the second storage subsystem. Often an administrative user may be asked whether he/she desires the newly defined logical volume to be “imported” into the new receiving storage subsystem to thereby make it available for use in the receiving second storage subsystem.
A problem may arise where a RAID level 6 logical volume is exported from the first storage subsystem and imported to a second storage subsystem that does not adequately support RAID level 6 storage management techniques. Most present-day storage subsystems utilize hardware assist circuitry to maintain desired performance levels for any given RAID storage management level. In other words, a first storage subsystem may include hardware assist circuitry for improving the performance of both RAID levels 5 and 6 while the second storage subsystem (e.g., an older “legacy” subsystem) may include hardware support only capable of adequately performing RAID level 5 storage management techniques. In addition, older legacy systems may provide efficient RAID assist circuitry support only for other RAID levels such as level 1 (mirroring) or even level 0 (striping without redundancy information added).
To resolve the problem of a RAID level 6 logical volume being received for import within a storage subsystem supporting only RAID level 5 or other RAID levels, three generic options have generally been proposed in the past. First, though the logical volume is recognized by the receiving storage subsystem, the storage controller therein may disallow a user from importing the newly defined logical volume into its control. The newly defined logical volume will simply remain unavailable to the second, receiving storage subsystem. A second prior solution involves allowing the importation of the newly discovered RAID level 6 volume but indicating that the volume is incompatible with capabilities of the receiving, second storage subsystem. In these first two options, integrity of the information stored in the newly discovered logical volume is maintained in that no user may be allowed access to the RAID level 6 logical volume.
A third general approach known in the art is to permit importation of the newly defined logical volume and to emulate the RAID level 6 storage management techniques utilizing software features rather than hardware assist circuits that may have been available to the exporting first storage subsystem. In general, this third approach of emulating RAID level 6 management utilizing software techniques within the second subsystem's storage controller provides prohibitively poor performance.
The parent application teaches another approach wherein the mapping of blocks of the RAID level 6 volume may be re-mapped so as to essentially ignore the additional redundancy information blocks of RAID level 6 and use only the blocks pertinent to RAID level 5 management without requiring movement of any blocks. This approach reduces the time required to make the imported volume available on the storage system that imports the volume. However, operation of the volume re-mapped as a RAID level 5 volume may be suboptimal in that the blocks are not as easily located on the volume as compared to a standard mapping of a RAID level 5 volume.
It is evident from the above discussion that a need exists for improved methods and systems for improved importation and exportation between RAID level 6 and RAID level 5 storage subsystems.